Creating incidents

#22

I’m really glad that helped!

While this is possible in theory, it would require customization, and lots of it. The ID field is tied to many aspects of the workflow and the source code / configurations in these places would need to be changed.

#23

I really appreciate your help. Thanks again.

#24

All the fields are working expect for incident id and ’ the assigned to’ field in in sercive now should be mapped with the person who acknowledges the incident

Assigned to - user who acknowledges

PagerDuty incident id - PagerDuty ticket #

for the incident number , I tried this , but didn’t work --> log_entries.channel.incident_number

#25

I would like to suggest:

  1. Add a new custom field to incidents, i.e. PagerDuty Number
  2. Create a new inbound field rule that sets the field to the value of the property in the payload: incident.incident_number

Then you can hide the PagerDuty incident ID if that’s not the information you wish to see, and display the custom field with the PagerDuty incident number.

As for the assigned to field, if it is not getting assigned to the user who acknowledges it, that may indicate that the user has no analogue in ServiceNow. Note, the way that it is done and how it works is a GlideRecord query on users for any that match the login email of the user in PagerDuty who acknowledged it. If it can’t find any, it will leave a telltale worknote on the ServiceNow incident that says “PagerDuty Incident was acknowledged by NAME-HERE, but ServiceNow could not locate user EMAIL-HERE to assign the incident to them.”

It could be that there is a difference in case of the email addresses, so that would be worth checking and reconciling if you’ve verified that a user with that email address does indeed exist in ServiceNow.

1 Like
#26

Thank you so much For your help Demitri . This is working as expected. Thanks!!!